feat: AVE-2026-00067 -- skill composition trust transfer (SCR-TrustLift) - #114
Merged
Merged
Conversation
Verified genuine gap during the eight-candidate audit sweep: keyword sweep clean, and structurally distinct from AVE-2026-00045 (Cross-App-Access Escalation, a single-session instruction-driven confused-deputy pivot) -- SCR-TrustLift requires no injected instruction and no compromised component at all; a downstream skill simply trusts an upstream skill's legitimate output as an authorization signal without independently re-verifying it. Sourced from arXiv 2606.15242 (SCR-Bench), scoped specifically to the TrustLift sub-mechanism (96.5%+ success across 4/5 backends) rather than all three SCR sub-types, per researcher-process.md's own guidance against drafting something too broad to fingerprint precisely. owasp_asi corrected mid-draft: initially assigned ASI01 by pattern-matching corpus usage, caught as wrong by direct verification against OWASP's own published category list (ASI01 is the narrow 'Agent Goal Hijack', not a catch-all) -- corrected to ASI03/ASI08, both independently verified against the primary source. mitre_atlas and nist_ai_rmf both left as researched, deliberate empty arrays: the closest ATLAS candidate (AML.T0053) describes a different mechanism, and independent research corroborates a real, documented gap in NIST AI RMF's MAP function for tool/component composition risk -- not omitted, checked and found genuinely absent.
…7-skill-composition-risk # Conflicts: # CHANGELOG.md # README.md # dist/ave-records-latest.json # dist/ave-records-latest.manifest.json
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
AVE-2026-00067: skill composition trust transfer, the SCR-TrustLift mechanism (MEDIUM, AIVSS 5.0). Second of five records from the eight-candidate verification audit's genuine gaps.
Why this is a genuine gap
Confirmed distinct from AVE-2026-00045 (Cross-App-Access Escalation): 00045 is a single-session, instruction-driven confused-deputy pivot. This mechanism requires no injected instruction and no compromised component at all -- a downstream skill simply trusts an upstream skill's legitimate output (an endorsement, audit finding, validation result) as an authorization signal without independently re-verifying it. Neither skill is dangerous in isolation; the vulnerability exists only in the composition.
Sourcing
arXiv 2606.15242, "Benign in Isolation, Harmful in Composition." SCR-Bench measured SCR-TrustLift at over 96.5% attack success across four of five model backends when a downstream decision is preceded by an upstream endorsement-like output, versus near-zero in isolation.
Scoped specifically to the TrustLift sub-mechanism rather than all three SCR sub-types (CapFlow, TrustLift, AuthBlur) the paper covers -- SCR-CapFlow and SCR-AuthBlur are related but structurally distinct, worth their own records if drafted, not folded in here to avoid a fingerprint too broad to be useful.
Framework-mapping corrections, caught by research not memory
owasp_asiwas initially drafted as["ASI01"]by pattern-matching how ASI01 appears across the existing corpus. Direct verification against OWASP's own published Top 10 for Agentic Applications page showed ASI01 is "Agent Goal Hijack" (hidden prompts redirecting agent purpose) -- not a match. Corrected to["ASI03", "ASI08"](Identity & Privilege Abuse; Cascading Failures), both independently verified against the primary source and genuinely fitting this mechanism.mitre_atlasandnist_ai_rmfare both deliberate empty arrays, not omitted fields: the closest ATLAS candidate (AML.T0053, "AI Agent Tool Invocation") describes an agent exploiting its own access to invoke tools, a different mechanism from a downstream skill trusting an upstream skill's output. Independent research also corroborates a documented gap in NIST AI RMF's MAP function for tool/component composition risk. Checked and found genuinely absent, not skipped.Validation
python3 scripts/validate_records.py: all 66 records valid.python3 scripts/check_fixtures.py: all 66 records have positive + negative fixtures.pytest tests/ -x -q: 264 passed.node scripts/build-records.js: dist regenerated; frozen v1.1.0 snapshot untouched.Scope notes
No detection-rule PR in bawbel/scanner -- separate tracker. Three more records from the same audit sweep to follow, each its own PR.